cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <bmcla...@algx.net>
Subject Re: Different Processors
Date Wed, 15 Dec 1999 17:44:02 GMT
Stefano Mazzocchi wrote:
> 
> Donald Ball wrote:
> >
> > On Tue, 14 Dec 1999, James & Sue Ann Birchfield wrote:
> >
> > > We have a servlet interface for talking to LDAP's using JNDI, and I can see
> > > a nice implementation of a processor.  As far as the MailProcessor, I was
> > > thinkong it would be as simple as the SQLProcessor is for connecting to a
> > > mail server something like:
> > >
> > > <serverinformation>
> > >  <mailserver>my.mail.com</mailserver>
> > >  <username>Jim</username>
> > >  <password>foobar</password>
> > >  <protocol>pop</protocol>
> > > </serverinformation>
> >
> > Wow, that's really kinda brilliant, I hadn't even thought about hooking up
> > cocoon as a mail client.
> 
> Yes, brilliant idea to have a webapp that wraps out mail resources. This
> is the same Jetspeed idea and would be really helpful for our mail lists
> to provide a web access, something like an Apache web portal for all the
> information resources going on in its projects.
> 
> Of course, Cocoon driven :)
> 
> > This does bring up a question that should be addressed now before we get
> > too many dynamic document processor entities. Should each processor claim
> > a namespace and only operate on tags that exist in that namespace?
> 
> Yes, we should define something like that.
> > It would make it harder to step on each others' toes if we did so.
> 
> Totally, that's the namespace idea.
> 
> > How would
> > the page author choose the namespace that is associated with SQLProcessor
> > if they didn't want to use the default?
> 
> What do you mean?
> 
> > Or is this something that will be addressed by XSP?
> 
> I'm thinking about having the content namespace driven with a
> configuration map that applies XSP logicsheets to the different
> namespaces so that something like this would make sense:
> 
>  <page xmlns="page.dtd"
>        xmlns:util="apache.org/cocoon/utils"
>        xmlns:xturbine="apache.org/turbine"
>        xmlns:xqul="apache.org/cocoon/sql-processor">
> 
>   <title>Hello, you've requested me <utils:count/> times.</title>
> 
>   <p>
>    Your shopping cart is currently: <xturbine:shopping-cart/>
>   </p>
> 
>   <p>
>    Your data is: <xsql:query>select * from Data</xsql:query>
>   </p>
>  </page>
> 
> and then you XSLT-style it.

Yes, yes, yes... I am a huge proponent of moving to component based
systems, and this is a significant step in that process.  The idea of
having "toolboxes" if you will of useful items, and those toolboxes
mapping to applications/frameworks makes a lot of sense, plus of course
makes development feasible.

Of course, as you know, this is really not posible in a constrained
environment (DTD/XML Schema) until XML Schema is more solid, because of
the nightmare of DTD for something that can include all sorts of
permutations of namespaces.  Wouldn't you agree?

-Brett

Mime
View raw message