Tim Williams wrote:
On 8/15/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
> On 8/14/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
...
> A lot of avalon and excalibur + a very little Cocoon for context and
> an (all things considered) wrapped up by a very little bit of Forrest
> code. I'm just suggesting that we've done nothing but wrapped some
> stuff here - "forrest technology" is a stretch. To recreate it, we
> could get context elsewhere but we'd need an equivalent to
> avalon/excalibur I think.
Come on, are you realy claiming that we need Avalon+Excalibur+Cocoon to
create a hashmap of possible matches to any given string?
I'm saying the matching/selection does not come from Forrest code.
They would need to be implemented. Source resolution/validity does
not come from Forrest code; it would need to be implemented.
No we do not need to implement it, we only need to use what is there.
Here is just one suggestion for each category:
Matching: http://jakarta.apache.org/oro/index.html
Source Resolution: java.net.* and/or HTTPCommons
Source Validity: http://ehcache.sourceforge.net/
Like I said:
All we need is pattern matching followed by a lookup then a lookup. See
my psuedo code later in the original post. The *concept* of the
Locationmap is Forrest technology and it can be reproduced without any
of the baggage Cocoon requires us to bring along.
...
I really should have been talking about the complexitites of writing a
generator. As we very rarely need to write transformers. Try writing a
generator that, for example, uses hibernate to communicate with a
relational database.
Same thing, except it's just a producer and not also a consumer. The
code to do this will be almost exactly the same in any other
SAX-event-streaming approach. But anyway...
You provide the code for a hibernate generator. But have you tried
deploying it in Forrest. Like I said nothing is as simple as you seem to
think. Just try it - writing code is easy - *using* it is hard.
> I think being in some sort of managed environment (e.g.
> Spring) is likely needed in any real-world approach. So I'd turn this
> around and ask where is the complexity?
First complexity: building Cocoon
Second complexity: building any component that has additional
dependencies
Third complexity: deploying a new (non-trivial) component within a plugin
Fourth complexity: a community that is pulling in many different
directions
There are many more but I will leave it at that. If you don't agree then
I suggest you actually try it before arguing the case. You can then tell
me where I am going wrong.
"Actually try" what? Surely you can be more constructive than
questioning my credibility here?
See above.
I'm not intending to question your credability as an individual, I am
questioning whether you have actually tried to deploy a non-trivial
Forrest application.
My point is that if it is not reasonably simple the vast majority of
coders will go an easier route (I have and I have been around Cocoon and
Forrest for about 5 years now).
I disagree. The sitemap is a way of *configuring* this complex
processing, it is not the processing itself. The sitemap has become an
XML programming language and I hate it for that reason.
Have you ever dived in to the implementation and tried to do anything
useful in there?
Again, what implementation? I've looked inside to the Treeprocessor
code in Cocoon, yes, and it is difficult to grasp. I did this when
doing the LM mounting stuff to see how mountnodes were implemented in
the sitemap - I like to think this was useful. I see no reason why
the average user would care about this stuff though.
The "average user" is not who we should be targeting, we are a
publishing framework not a publishing tool. We need developers.
On the other hand, if we really are targetting users then we should
consider whether they have the resources and access to install a
monolothic web application to do simple publishing. My experience is
that they don't
So we are not attracting developers because of the complexity of the
code we are built on and we are not attracting real users because they
cannot deploy the code. The root cause of both problems, in my opinion,
is the same.
<map match="foo/bar/**">
<aggregate>
<location src="..." required="true"/>
<location src="..." required="false"/>
</aggegate>
<map>
Fair enough, move the aggregation to the Locationmap. This looks very
similar to the sitemap though, no?
Yes, that is one part of the sitemap that we need (there are others). I
don't intend to claim it was an improvement, only illustrate that we do
not need the sitemap to do it. There are many other ways we could do it,
I'm only providing examples for this RT.
It's also worth noting that doing the configuration in this way removes
the indirection between the sitemap and the locationmap, which is a nice
side-effect.
I am not disagreeing with
the performance problem itself. For example, I think a much larger
contributing factor is that we re-generate everything for changes that
really impact only a small part of a site. This has nothing to do
with Cocoon baggage; we just have an implementation that isn't very
efficient.
This *is* a Cocoon problem, we've been looking at ways to solve it for
many years and we can't becuase Cocoon gets in the way. See the
archives. In fact this is another strong argument for using
>> Ready Made Transformations
>> --------------------------
>>
...
> You seem to be
> suggesting that Cocoon requires some big overhead to do transforms and
> that's simply not the case.
That's right, I call 40Mb of bloat a fair big overhead for doing XSLT
transformations.
This time I really am oversimplifying, but I hope you see my point -
certainly that is how my customers see it. As a result I ended up, in
most cases, writing a series of Java components that I wired together
manually and plugged directly into whatever framework they were using.
This RT is about doing this in a more felxible and reusable way.
You're customers are likely just intimidated by the
Cocoon-learning-curve itself rather then 40Mb of jar files.
I think I know my customers pretty well. When they can write a
transformation in about 5 lines of code with a couple of megs of jars
they don't even get past the 40Mb dowload.
However, you are right, for those that do get past the download, they
are intimidated by the learning curve and chaotic implementation of Cocoon.
> I'm struggling to figure out what you think is forcing us into our
> current apparently overly complex solution. Is it the sitemap grammar
> that is complex?
Not the grammar itself (although I do hate the fact that we are now
programming using the sitemap). The complexity is in processing of that
gramar whic results in the selection of the processing path to take.
I don't understand. Treeprocessor? NodeBuilders? Matchers?
We want to do input->transformation->output
We do not need treeprocessors and nodebuilders (along with much of the
other sitemap stuff).
>> Conclusion
>> ----------
>>
>> Cocoon does not, IMHO, bring enough benefits to outweigh the
overhead of
>> using it.
>>
>> That overhead is:
>>
>> - bloat (all those jars we don't need)
>
>
> this is going to be addressed with maven (argghhh) and/or osgi someday
> - it's a recognized issue by many cocooners.
"someday" is the optimal word there. I've been waiting too long.
C'mon, you're an OS veteran here. Patches welcome, right?
Right, and where are the devs to create those patches? Why are they not
here? I think I've made my view on this pretty clear.
Why am I not patching Cocoon? Because I don't think it will be time well
spent. I don't use it outside of Forrest and I don't use Forrest
commercially anymore because I don't believe it is the right framework
for my needs.
Am I alone in this view? Maybe, this RT will tell me. If I am alone then
of course, Forrest should continue and...
If we reject this RT based on this argument then I want to see Forrest
developers helping Cocoon sort this out rather than standing by waiting
for it to happen.
Ok, I threw the "maven" thing in with fingers crossed. I'd rather
they go back to ant personally, maven is silly. I have a high-speed
connection and it takes forever to download libs each time I *attempt*
to build only to see it fail 10 minutes into it. Argghhh...
I feel your pain, and I'm in total agreement, but the Cocoon devs need
to hear it rather than the Forrest devs. Right now Cocoon is fairly
split on this point.
Again, strictly talking about the components, what you describe above
as a "plugin" is an implementation of XMLProducer and XMLConsumer.
I'm not seeing the benefit/difference but don't waste time on
responding until I actually put the effort into looking at your
psuedo-code.
I'm not sure why you keep raising this XMLProducter/XMLConsumer point.
I've never said anything about losing it, I've always said it is good
and we should keep it, but we don't need to keep all that Cocoon is just
for that little bit of good stuff.
Looking at the pseudo code won't help here as it didn't cover this
aspect as I'm not really talking about changing the how the information
flows internally, I'm talking about the rest of the baggage that plugs
it all together.
Ross
