Re: sitemap design

[Stefano Mazzocchi <st...@apache.org>]

On 8 Nov 2003, at 12:02, Guido Casper wrote:

> Stefano Mazzocchi wrote:

>> Careful. I'm against the use of
>>
>>   <match src="something">
>>   </match>
>>   <read/>
>>
>> as well. The proper way should be
>>
>>   <match src="something">
>>    ...
>>   </match>
>>
>>   <match src="**">
>>    <reader/>
>>   </match>
>>
>> having the logic processing not following the element nesting, is,
>> IMO, very confusing and very bad practice.
>>
>> In the original sitemap design, it was *NOT* possible to have pipeline
>> components inside <pipeline>, only matchers. This is something that
>> was introduced while I wasn't watching, just like actions.
>>
>> Yes, actions are not the only the only things I dislike about the
>> sitemap: the tree processor introduced new ways of dealing with things
>> (like having resources without generators or serializers, or pipeline
>> components in pipelines without matchers)... but all these things
>> ended up being more harm than good from a usage perspective.
>>
>> So, what's the point of introducing something and then come out with
>> "best practices" that prevent you from using them?
>
> Sorry if I added confusion.
>
> Yes, "best practices" has always been hard to come up with for Cocoon. 
> This
> certainly has to do with the variety of usages users come up with. 
> "Best
> practices" tend to have a short life anyway.
>
> I always wondered what the real difference between actions and 
> matchers is
> and (thanks to the power of expressive names) came to the conclusion 
> that
> it's the silent consensus to keep matchers side effect free while the 
> side
> effect of actions is their primary purpose.

> You seem to be with Rickard Öberg's third principle for making software
> frameworks:
> "A framework's power comes not from what it allows, but from what it 
> does
> not allow"

Of course!

> However this comes just after:
> "If you make a decision, be sure that it counts"
> http://www.jroller.com/page/rickard/20030419
>
> I somehow always had the feeling that Cocoon is different and its
> unrestrictiveness (is this the right word?) attracts the creatives and 
> it's
> unforeseeable what they come up with. Cocoon is not just a framework 
> for
> building aplications. It's more of a framework for building 
> frameworks. But
> that's just my opinion.

Cocoon is definately *not* a framework for frameworks. Cocoon is a 
vertical framework (specializes in one thing) while Avalon is an 
horizontal one (covers many things).

The more cocoon becomes 'horizontal', the weaker it becomes. This is 
why I'm against the "operating system for the web" concept. It's too 
wide. Avalon suffers from marketing problems: it can be anything for 
anybody (but rarely out of the box!), I don't want cocoon to suffer the 
same thing.

Actions, in my mind, represent a vertical design going horizontal. We 
spent 6 months designing the sitemap and actions came out in a few 
weeks, stolen from webapp frameworks but with no idea on where they 
were going to be. Introducing them was the biggest design mistake this 
community ever made.

There is an easy design pattern to know if your sitemap component is 
good or bad: ask yourself:

  can you reuse it?
  does it contain logic that is specific for your application?

The number of reusable actions is *very* small... and those actions 
require normally so many parameters that the sitemap just becomes a 
mess.

This shows that the logic that normally actions contain should not be 
there... it required a completely different paradigm shift.

Which is what we did introducing the notion of flow.

Matchers were not abused because the matchers we ship are *highly* 
reusable. As for generators, transformers, serialziers and selectors. 
All of them were designed to be reusable.

Actions were introduced to keep stuff that is application specific.... 
thus they fell *out of place* in a context were component reusability 
is much greater.

I believe that people used Actions instead of Matchers for many reasons:

  1) the name
  2) the samples suggested that less reusability was not so bad
  3) matchers cannot redirect

The things I would like to see deprecated in the sitemap are:

  1) action/action-sets (flow + real blocks make them unnecessary)
  2) resources (virtual components and the cocoon: protocol make them 
unnecessary)
  3) the ability to have generators/transformers/serializers inside 
<pipeline> (only matchers/error-handler should be there) [this 
shouldn't have been there in the first place!]

Before those who have invested a lot in actions jump on me, let me 
guarantee you that I don't plan to propose this anytime soon.

But this is my opinion on the sitemap design.

--
Stefano.

Re: sitemap design

[Giacomo Pati <gi...@apache.org>]

Stefano Mazzocchi wrote:
 >
> The things I would like to see deprecated in the sitemap are:
> 
>  1) action/action-sets (flow + real blocks make them unnecessary)

+1

>  2) resources (virtual components and the cocoon: protocol make them 
> unnecessary)

+1

>  3) the ability to have generators/transformers/serializers inside 
> <pipeline> (only matchers/error-handler should be there) [this shouldn't 
> have been there in the first place!]

+1

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: Namespace problems wit Hibernate

[Hugo Burm <hu...@xs4all.nl>]

Thanks,
Problem solved.
Hugo

> -----Original Message-----
> From: Ugo Cei [mailto:u.cei@cbim.it]
> Sent: Saturday, November 08, 2003 7:50 PM
> To: dev@cocoon.apache.org
> Subject: Re: Namespace problems wit Hibernate
> 
> 
> Hugo Burm wrote:
> > 1) I have my own little Avalon component defined in 
> cocoon.xconf. It is a
> > factory component that should generate Hibernate sessions. When 
> Cocoon is
> > started by Tomcat, my component starts Hibernate. Hibernate 
> tries to read
> > its configuration files. These files are XML files. Everything 
> seems to work
> > fine, but when there is an element like eg <map> in this 
> configuration file,
> > the boot process starts to complain about the fact that "<map>" 
> should have
> > an attribute "role". The "<map>" element in my Hibernate 
> configuration file
> > does not need this attribute "role".  This looks like a 
> namespace problem.
> 
> What version of the Hibernate mapping DTD are you using? Version 2.0 
> does not require the "role" attribute, but version 1 does. See 
> <http://hibernate.sourceforge.net/hibernate-mapping.dtd> versus 
> <http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd>.
> 
> 	Ugo
> 
> 

Re: Namespace problems wit Hibernate

[Ugo Cei <u....@cbim.it>]

Hugo Burm wrote:
> 1) I have my own little Avalon component defined in cocoon.xconf. It is a
> factory component that should generate Hibernate sessions. When Cocoon is
> started by Tomcat, my component starts Hibernate. Hibernate tries to read
> its configuration files. These files are XML files. Everything seems to work
> fine, but when there is an element like eg <map> in this configuration file,
> the boot process starts to complain about the fact that "<map>" should have
> an attribute "role". The "<map>" element in my Hibernate configuration file
> does not need this attribute "role".  This looks like a namespace problem.

What version of the Hibernate mapping DTD are you using? Version 2.0 
does not require the "role" attribute, but version 1 does. See 
<http://hibernate.sourceforge.net/hibernate-mapping.dtd> versus 
<http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd>.

	Ugo

Namespace problems wit Hibernate

[Hugo Burm <hu...@xs4all.nl>]

Environment: Windows XP, JDK 1.4, Tomcat 4.27, Cocoon 2.1.3 CVS 7 nov 2003


1) I have my own little Avalon component defined in cocoon.xconf. It is a
factory component that should generate Hibernate sessions. When Cocoon is
started by Tomcat, my component starts Hibernate. Hibernate tries to read
its configuration files. These files are XML files. Everything seems to work
fine, but when there is an element like eg <map> in this configuration file,
the boot process starts to complain about the fact that "<map>" should have
an attribute "role". The "<map>" element in my Hibernate configuration file
does not need this attribute "role".  This looks like a namespace problem.
Why does cocoon assume some kind of an Avalon namespace when parsing
cocoon.xconf? I tried to create my own namespace for my Hibernate
configuration file, but that did not work.
Anyone?



2) I excluded Deli in the blocks. Deli creates about 200 lines of error
messages about "com.hp.hpl.jena.rdf.." when Tomcat starts Cocoon. These
errors occur with a vanilla build of Cocoon and have nothing to do with the
rest of this e-mail. This problem was reported before on the user list and
Mikael Björn pointed to the cause of this problem.


Hugo Burm